

Animal, Vegetable, or Mineral: 
The 3172 Interconnect Controller 

As networked personal computers and workstations gain equal footing with tradi¬ 
tional terminal-to-host computing, one challenge for IBM systems managers is nego¬ 
tiating connectivity between these LAN-based devices and host computers. Finding 
a cost-effective solution for LAN-to-mainframe communications is emerging as a 
very significant issue. 

To address this requirement for LAN-to-mainframe communications, IBM 
announced the 3172 Interconnect Controller in October 1989. Because the 3172 is a 
new product category for IBM, there is some confusion over what it is and what it 
does. This article attempts to demystify the 3172 by addressing some of the basic 
issues surrounding it, in particular: 

• What the 3172 does and doesn’t do 

• What the differences are between the three models 

• Whether (and how well) the 3172 can be managed 

• Hidden costs and confusion 

• How the 3172 compares to similar offerings from other vendors 

• What the future holds for this product category 

(continued, on page 2) 


Integrating TCP/IP into SNA 
Part III: Implementations 

This article is the third installment in a series intended to assist users facing the chal¬ 
lenge of integrating TCP/IP into traditional subarea SNA networks. Part I focused 
on transport and network connectivity. Part II discussed application-level issues sur¬ 
rounding this integration and looked at several approaches to and aspects of TCP/IP 
and SNA integration. Primarily, this third installment is a composite case study of 
companies that have introduced TCP/IP into an SNA environment—the decision 
processes, implementation experience, benefits derived, and plans, if any, for further 
integration. This article also briefly reviews TCP/IP products for IBM’s ADC (Unix- 
based) systems as well as the offerings on S A A systems, especially the newly- 
announced TCP/IP Version 2 Release 2 for MVS. 

(continued on page 13) 
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The 3172: What It’s Got 
and What It’s Not 

The 3172 Interconnect Controller is a product line 
that facilitates LAN-to-mainfirame and, to a lesser 
extent, remote VTAM channel-to-channel commu¬ 
nications via a rack-mounted, Intel microprocessor- 
based, microchannel architecture-based controller. 
(The 8232 LAN Channel Station, which the 3172 
replaced, also handled LAN-to-mainframe commu¬ 
nications but supported only TCP/IP.) 


SNA Perspective believes that, in order to fully 
grasp what the 3172 is, it’s important to first under¬ 
stand what it’s not. 

• The 3172 is not a communication controller 
(37xx) or a cluster controller (3174). While 
communication controllers and cluster con¬ 
trollers can directly identify themselves to other 
devices and establish sessions, the 3172 cannot 
(see Table 1). 

• Along the same lines, the 3172 is not an SNA 
network addressable unit and does not have log¬ 
ical units (LUs) or physical units (PUs) that 
identify it to the network. 


• The 3172 is not a bridge. The 
3172 does move traffic, but it 
does not directly connect LANs 
(see Figure 5 in SNA Perspective, 
May 1992). While the technology 
that underlies the 3172 is admit¬ 
tedly capable of being developed 
to handle bridging, IBM has not 
exploited this potential and SNA 
Perspective does not believe that 
it will in the near future. 

• The 3172 is not a router—it does 

not directly connect LANs and, at 
this point, does only limited pro¬ 
raft/e 1 tocol processing. There is an 

exception—the TCP/IP Offload 
feature enables basic IP routing 
between different LANs. 

• The 3172 is not, strictly speaking, 
a gateway. SNA Perspective sub¬ 
scribes to a rigid industry defini¬ 
tion that a gateway processes 
level four and up in the protocol 
stack. Because the 3172 serves 
largely as a transparent data pass¬ 
through it does not qualify as a 
gateway, even though IBM often 
refers to it as a LAN-to-main¬ 
frame gateway. 

That said, what is a 3172? It’s an 
interface for LAN-to-channel 
communications—a simple concept 
that has been prone to considerable 
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3172 Is Not a 3745, a 3174, or a 6611 


IBM Product 

LUs 

PUs 

Sessions 

Bridging 

Routing 

3172 Interconnect Controller 

No 

No 1 

No 

No 

No 

3745 Communication Controller 

No 

Yes 

Yes 

No 

Yes 2 

3174 Cluster Controller 

Yes 

Yes 

Yes 

No 

No 

6611 Bridge/Router 

No 

Yes 3 

No 

Yes 

Yes 3 


1 The 3172 ICP has a PU 2 that is used for network management only. 

2 The 3745 routes SNA and, with NCP version 6, also routes IP. 

3 The 6611 is a multiprotocol router that routes, or will route, several protocols 
including APPN (PU 2.1) but not subarea SNA. 
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misunderstanding, mainly because of the number of 
LAN types and LAN protocols that exist. Although 
the 3172 is also capable of remote mainframe-to- 
mainffame and mainframe-to-control unit communi¬ 
cations, these appear to be less strategic to IBM at 
this time (see Figure 1 on page 2). 


The 3172 Family 

Families, whether people or products, are some¬ 
times difficult to figure out at first glance, but SNA 
Perspective believes that a little background can 
help. For the 3172, life began in parallel at two dif¬ 
ferent IBM divisions in Kingston, New York and 
Research Triangle Park, North Carolina. IBM’s 
Enterprise Systems (that is, mainframe) group in 
Kingston focused on developing a product for wide 
area channel-to-channel communications. The 
Networking System group in Research Triangle 
Park leaned more toward LAN-to-mainframe con¬ 
nectivity. Both groups decided to co-develop a 
single product based on a microchannel PS/2 that 
incorporated wide area channel-to-channel and 
LAN-to-mainframe connectivity. 

Research Triangle Park has since taken full respon¬ 
sibility for the 3172, and the product has taken on its 
LAN-to-mainframe connectivity preference. IBM’s 
recent announcements indicate that the product will 
continue to develop in that direction. 

IBM announced the 3172 model 1 in October 1989. 


The 3172 and ICP are configured and controlled by 
the companion 3172 Operator Facility software. 

The Operator Facility runs on a PS/2 with OS/2, and 
configurations can be transfered using 3.5-inch 
diskettes or over a LAN (using OS/2 Communi¬ 
cations Manager) with limited NetBIOS (see 
Figure 2). Although this indicates that IBM could 
support LAN access to the mainframe via NetBIOS, 
SNA Perspective does not expect IBM to develop 
this functionality. The 3172 must be configured 
with at least one channel adapter and a maximum of 
two. The 3172 Interconnect Enhancement feature 
must be purchased in addition to ICP to enable SNA 
traffic to flow through the 3172 to the host. As with 
any family, it’s instructive to examine and evaluate 
each member individually. 

Model 1 

The model 1 is the most versatile, albeit the slowest, 
member of the 3172 family. It uses an Intel 386 
processor and 8 MB of RAM to support LAN-to- 
mainframe communications. It supports a broader 
selection of LANs and protocols than either of its 
siblings. The Remote Channel-to-Channel feature 
supports Enterprise System Connection (ESCON) 
and parallel channels and remote communications 
of up to four high-speed links (Tl, CEPT (El), or 
HSDS (Jl)). 

The model 1 can be configured for LAN-to-main- 
frame or channel-to-channel communications, but 
not for both. LAN and protocol support for the 
model 1 are given in Table 2 on page 4. 


Since then, the product family has grown to three 
members, the most recent one, model 3, announced 
in June of this year. Each member of the family is 
based on IBM’s Intel microprocessor/ microchannel 
architecture, similar to the PS/2, and can run the 
Interconnect Controller Program (ICP) software. 


Model 1 supports up to two parallel or two ESCON 
channel connections. The parallel channel (also 
called bus and tag) is a block multiplexer channel 
that supports data-streaming rates of up to 4.5 
megabytes per second (MBps), or in LAN terms, 
about 36 megabits per second (Mbps). ESCON is a 



fiber-optic, point-to-point, serial con¬ 
nection supporting data rates up to 10 
MBps, or about 80 Mbps. ESCON 
can be used only for channel-to-chan- 
nel configurations of the 3172. 
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NetBIOS 
3.5" diskettes 


Since the original announcement in 
1989, IBM has changed its commit¬ 
ments for model 1 by discontinuing 
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support for token bus (IEEE 802.4), OSI/MMS, and 
MAP. In addition, IBM has not yet fulfilled its 
statement of direction for OSI/Communications 
System (OSI/CS) support except over Ethernet 
Model 1 will not run the just-announced ICP 
version 3 or probably any future release, effectively 
limiting support to what is currently available in 
version 2. Support of higher-performance LANs is 
beyond the capability of the current model 1 
anyway. 

In sum, the capabilities unique to the 3172 model 1 
are channel-to-channel functionality, support for 
TCP/IP over PC Network, and support for DECnet 
over Ethernet version 2 (in conjunction with 
Interlink host software). SNA Perspective believes 
that, except for these unique functions, user needs 
can be better met by the newly announced model 3. 


Supported Protocols/LANs 


Protocol 

Ethernet 
version 2 

IEEE 

802.3 

IEEE 

802.5 

PC 

Network 

FDDI 

Model 1 






TCP/IP 

✓ 

✓ 

✓ 

✓ 


SNA 


✓ 

✓ 



OSI 


✓ 

SOD 



DECnet 






Model 2 






TCP/IP 

✓ 

✓ 

✓ 


✓ 

SNA 


✓ 

✓ 


✓ 

OSI 


SOD 

SOD 


SOD 

Model 3 






TCP/IP 


✓ 

✓ 


✓ 3 

SNA 


✓2 

✓2 




1 DECnet is supported only in conjunction with Interlink’s 
SNS/SNA Gateway software on the host, 

2 SNA is not supported with TCP/IP Offload. 

3 TCP/IP over FDDI is supported only with TCP/IP Offload 
software; the ICP version 3 software does not support 
FDDI on model 3. 

SOD = Statement of Direction 


Table 2 


Model 2 

With model 2, IBM appears to have begun more 
actively shaping the 3172’s market focus, with an 
emphasis on higher speed LAN-to-mainffame con¬ 
nectivity. 

Physically, the model 2 is a higher performance unit 
than the model 1, using a 486 microprocessor. This 
faster chip, combined with the ability to handle larg¬ 
er form-factor (and higher performance) adapters 
and its greater power and cooling capacity, make the 
model 2 a faster, though more expensive box. The 
model l ’s base unit price is $16,220, whereas the 
model 2’s base unit price is over $50,000. 

Model 2 also represents a major departure from 
VTAM channel-to-channel support. The standard 
3172 model 2 is a LAN-to-mainframe product that 
does not allow channel-to-channel connectivity. To 
“fulfill” its statement of direction to provide channel- 
to-channel communications on model 2 (and, SNA 
Perspective speculates, perhaps to still the interdivi- 
sional waters between RTP and Kingston), IBM and 
AT&T Paradyne are jointly developing a solution 
based on the 3172 model 2, called the AT&T 
Paradyne XL/5000, which will provide remote 
Tl/DS-3 SNA channel-to-channel functionality. 

The XL/5000 will provide mainframe-to-control 
unit functionality initially, and add mainframe-to- 
mainframe sometime in the future (see Figure 3 on 
page 5). 

Although AT&T Paradyne is responsible for the 
XL/5000’s sales and marketing, SNA Perspective 
believes that IBM will provide the enhanced 
ESCON and Tl/DS-3 teleprocessing boards for the 
product. This joint product will be the only means 
by which model 2 supports remote channel-to-chan- 
nel connections. 

An important feature of model 2 is its support for 
the Fiber Data Distributed Interface (FDDI). The 
3172 was IBM’s first FDDI interface and, while 
IBM’s investment acknowledges the importance of 
this emerging technology, it also implicitly indicates 
IBM’s recognition that high-performance desktop 
computing—both on high-powered personal com¬ 
puters and engineering workstations—is here to stay. 
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Model 2’s support of FDDI allows organizations to 
consolidate numerous LANs onto a single backbone 
without sacrificing host access (see Figure 4). It 
also supports LANs in engineering and scientific 
environments where increased bandwidth is 
required. 

A restriction with the FDDI support is that only one 
FDDI adapter (plus two other low-speed LAN 


adapters) can be installed per 3172. A further and 
more significant restriction is that only one protocol, 
either TCP/IP or SNA, can be supported over that 
one $26,000 adapter. IBM recognizes that this is an 
expensive restriction for its customers, and is look¬ 
ing at possibly supporting multiple FDDI adapters 
in one 3172 or multiprotocol support over a single 
FDDI adapter in the future. Table 2 on page 4 
shows model 2’s LAN and protocol support. 


Model 3 

The 3172 model 3, which was 
announced this June and is expected 
to ship at the end of September, is fur¬ 
ther evidence of IBM’s commitment 
to LAN-to-mainframe connectivity. 

Physically, model 3 uses a 486SX 
microprocessor and busmaster adapter 
cards. Busmaster adapters control the 
data transfer between the adapter and 
system memory or other adapters 
themselves, offloading this task from 
the system CPU. Because model 3’s 
technology is both more advanced 
and less expensive from that used in 
model 1, model 3 effectively obso- 
letes model 1 for all but channel-to- 
channel, DECnet, and PC Network 
connections. IBM has told SNA 
Perspective that it does not intend to 
support channel-to-channel connectivity with the 
model 3. 


3172 Channel-to-Channel Comparison 


Remote mainframe-to-mainframe 

Host Host 



Remote mainframe-to-control unit 

Host 



* IBM and AT&T Paradyne state that a future release of XL/5000 will support host-to-host. 


Figure 3 


FDDI Consolidated Backbone 



* or 3172-3 with TCP/IP Offload 


Model 3 does support a reasonable offering of 
LANs and protocols (see Table 2 on page 4) but it 
has a few missing pieces. While the TCP/IP 
Offload software, discussed below, does support 
FDDI LANs, the ICP version 3 software used for all 
other protocol support does not support FDDI on 
model 3. We expect to see more extensive FDDI 
support in a future release. 


Model 3 also has a new option for protocol support: 
customers can run either the standard ICP software 
or a new program called TCP/IP Offload. TCP/IP 


TCP/IP Offload 


Figure 4 
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Offload does what its name implies—it takes on 
some of the protocol processing formerly done by 
the host and saves CPU cycles (see Figure 5). This 
does not replace TCP/IP on the host; TCP/IP for 
MVS V2R2 is still required on the host 


Also, the logistics of having a monitor and keyboard 
connected to a rack-mounted controller is rather 
awkward. But, if users are supporting TCP/IP on 
the host extensively and/or the mainframe is heavily 
loaded, TCP/IP Offload will prove valuable. 


TCP/IP Offload runs on OS/2 version 1.3 with 
TCP/IP for OS/2 version 1.2.1, and does not use 
ICP software. This means that a 3172 model 3 run¬ 
ning TCP/IP Offload can process only TCP/IP data; 
multiprotocol environments will need the ICP 
version 3 software. Configuration and control of the 
3172 with TCP/EP Offload is much different from 
configuration and control with ICP—a keyboard 
and monitor must be attached (as part of the 3172 
model 3 Offload Hardware Feature), and all config¬ 
uration and control is done locally. With ICP, in 
contrast, configuration and control functions are 
done at a separate OS/2 workstation using the 
Operator Facility program, and up to sixteen con¬ 
trollers can be configured and controlled (one con¬ 
troller at a time) over the LAN, or configuration 
diskettes generated for many 3172s. The loss of 
operator functionality will be a concern to users, 
particularly those with other 3172s running ICP. 


TCP/IP Offload on the 3172 


S/370 



Figure S 


SNA Perspective sees TCP/IP Offload as a fortifica¬ 
tion of IBM’s commitment to the TCP/IP market and 
does not expect IBM to develop offload programs to 
support any additional protocols. We believe this 
because IBM’s greatest success with the 3172 has 
primarily been in TCP/IP environments, as an add¬ 
on sale to the purchase of host TCP/IP software. 


Network Management 

The 3172 can be managed with any (or a combina¬ 
tion) of three network management utilities: the 
Operator Facility, NetView, or a Simple Network 
Management Protocol (SNMP) monitor. Each tool 
provides slightly different capabilities (see Figure 6 
on page 7). 

Operator Facility 

The Operator Facility, which is used to install and 
configure the 3172, also provides local management 
for up to sixteen 3172s over the LANs. While the 
Operator Facility does not provide integrated net¬ 
work management, it can be used to view status and 
error logs, and directly manage changes such as 
software updates and configuration changes. The 
3172 sends status updates to the Operator Facility 
which are shown on the status field. 

The Operator Facility comes with the ICP software, 
the TCP/IP Offload software does not include an 
Operator Facility; therefore a model 3 running 
TCP/IP Offload cannot be managed with this utility. 

NetView 

To support NetView management on the 3172, a PU 
type 2 is implemented in the ICP software. Network 
management information flows between NetView 
and the 3172 across a separate subchannel (and 
SNA session) than the LAN-to-mainframe traffic. 
The 3172 Interconnect Enhancement feature, which 
is required to enable SNA traffic flow through the 
3172 to the host, also enables the PU 2 in the ICP 
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for network management from NetView. Even if 
the 3172 is only carrying TCP/IP traffic from the 
LAN, the Interconnect Enhancement feature is 
required if the customer wants to manage the 3172 
from NetView. The Remote Channel-to-Channel 
feature also supports the network management 
flows between NetView and the 3172. 

NetView’s Central Site Control Facility (CSCF) can 
be used to obtain configuration and statistical 
information and to view the 3172 system log. 
Unfortunately, IBM has not yet fulfilled its state¬ 
ment of direction made on September 5,1990 to 
support NetView Distribution Manager (DM), 
because many of its functions are provided by 
Operator Facility. For IBM to realize its goal of 
central management through NetView, each net¬ 
working component, particularly contemporary 
components such as the 3172, must be visible to 
NetView and support all the NetView functionality 
that is applicable, including Distribution Manager. 


The 3172 model 3 running TCP/IP Offload cannot 
currently be managed by NetView. 

SNMP 

The 3172 can be managed using SNMP network 
management, although in a nonstandard way. IBM 
had to work around the fact that the 3172 with ICP 
is not an IP node, which is a requirement for SNMP 
manageability. 

To overcome this limitation, IBM created an SNMP 
subagent for the 3172. The subagent resides in 
IBM’s TCP/IP for VM or MVS (version 2 or later) 
and is a receptacle for 3172-related management 
information bases (MIBs). The 3172 ICP communi¬ 
cates with the host subagent via a proprietary data 
flow. Creating this subagent meant that IBM had to 
customize its host TCP/IP software. Because of 
this, users hoping to manage their 3172 can only run 
certain versions of IBM’s TCP/IP and cannot use 
other vendors’ host software. For example, many 
users have Interlink’s TCP/EP soft¬ 



ware on their mainframe and will not 
be able manage thei r 3172 with 
SNMP. IBM’s subagent customiza¬ 
tion includes SNMP GET and traps 
but does not implement the SNMP 
SET command, which means that 
SNMP can only be used to monitor 
the 3172 but cannot effect any 
changes. This proprietary subagent is 
not used with the TCP/IP Offload nor 
does it include its own SNMP agent. 
However, SNA Perspective hopes that 
IBM will add SNMP management 
capability to TCP/IP Offload by the 
time it ships in September. 


Performance 

IBM has not published much perfor¬ 
mance benchmarking for the 3172. 
IBM provides the following statistics 
for token ring SNA LAN-to-channel 
performance: 
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* The 3172 model 1 throughput is comparable to 
the 3745 model 210 

• The 3172 model 1 is twice as fast as the 3174 

IBM reports that the performance of model 2 and 
model 3 is almost identical. Furthermore, they both 


3172 Model Comparison 


Base unit 

Model 1 

Model 2 

Model 3 

Base unit 
Architecture 

Micro Channel 32 bit 

Micro Channel 32 bit 

Micro Channel 32 bit 

Processor 

80386DX (25 MHz) 

80486DX (25 MHz) 

80486SX (25 MHz) 

RAM (MB) 

8 

8 

8 

Hard drive (MB) 

30 

80 

80 

Maximum connections 



LAN 

4 

4 1 

4 2 

Channel 

2 

2 

2 

Primary modes 3 . 4 



LAN-to-host 

✓ 

✓ 

✓ 

Remote channel- 
to-channel 

✓(T1) 

✓(T1, DS-3) 


Channel connections 5 



Parallel 

✓ 

✓ 

✓ 

ESCON 

✓ 

6 


Controller software 



3172 software 




ICP 7 

VI or V2 

V2 or V3 

V3 11 

TCP/IP Offload 8 

IBM host software for CP 

NA 

NA 

V112 

VTAM 9 

3.4 

3.4 

3.4 

TCP/IP for VM 10 

2.0 

2.2 

2.2 

TCP/IP for MVS 10 

1.0 

. 2.0 

2.0 

AIX/370 10 

1.2 

1.2 

1.2 

AIX/ESA 10 

NA 

2.1 

2.1 


are about 30 percent faster than model 1 with SNA 
traffic and 100 percent faster than model lwith 
TCP/IP traffic when ICP version 3 is used. 

IBM has also conducted TCP/IP performance test¬ 
ing using TCP/IP Offload feature in a Model 3. 

This testing indicates that signifi¬ 
cant TCP/IP loading on the host is 
reduced by 30 percent. On the 
other hand, as expected, total 
3172 model 3 throughput using 
TCP/IP Offload is significantly 
reduced compared to using ICP. 


1 Up to one FDDI LAN is permitted. When an FDD! connection is included, a 
maximum of two Ethernet and/or token ring adapters can also be installed. 

2 Only when TCP/IP Offload software is used, up to one FDDI LAN is permitted. 
When an FDDI adapter is installed, a maximum of two Ethernet and/or token ring 
adapters can also be installed. 

3 3172 cannot operate in LAN-to-host and channel-to-channel modes at the 
same time. 

4 Model 2 channel-to-channel mode will be supported only by the AT&T Paradyne 
XL/5000. 

5 For LAN-to-mainframe, model 1 supports only parallel channel. 

6 ESCON support on model 2 will only be provided through the AT&T Paradyne 
XL/5000. 

7 ICP software includes Operator Facility. 

8 TCP/IP for MVS Version 2 Release 2 is required to run TCP/IP Offload. 

9 Required only for SNA connectivity. 

10 Only one of these is required for TCP/IP connectivity. 

11 ICP 3 does not support FDDI on the model 3. 

12 Model 3 can run TCP/IP Offload (on top of OS/2 version 1.3 and TCP/IP for 
OS/2 version 1.2.1) software instead of ICP. 


Pieces and Pricing 

With a product like the 3172 there 
are a lot of good reasons to be 
confused. The product category 
is new and it takes time for the 
market to understand any new 
technology. Moreover, most 
potential customers don’t have 
anything to which they can readily 
—and accurately—compare the 
3172. See sidebar “A Chron¬ 
ology of Confusion” on page 11 
for more on this issue. 

Finally, figuring out all of the 
components necessary to operate 
the 3172—hardware, adapters, 

3172 software, and host soft¬ 
ware—creates more confusion. 
The sections that follow attempt 
to sort out what is needed when 
stalking the elusive 3172. (See 
Table 3.) 

Getting the Right Software 

To run the 3172, you not only 

have to have the right software 
for the box itself, you also have 
to make sure you’re running 
compatible host software. 


Table 3 
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On the 3172 side, the biggest issue is making sure 
that the version of ICP you’re running supports the 
functionality that you require, a somewhat thorny 
issue for ICP version 3 in particular. For example, 
ICP version 3 supports Ethernet, token ring, and 
FDDI LANs on the model 2 but it does not support 
FDDI on model 3. To run FDDI on model 3, the 
box must be configured to run TCP/IP Offload soft¬ 
ware. To support SNA LAN traffic on any 3172, the 
Interconnect Enhancement feature must be pur¬ 
chased in addition to ICP. 

On the host side, the required software varies 
depending on whether you’re supporting SNA or 
TCP/IP. To support SNA traffic on the 3172, the 
host must be running VTAM version 3.4 or later— 
an expensive and time-consuming upgrade that 
many IBM users have not yet made. Similarly, to 
support TCP/IP traffic on the models 2 or 3, the host 
must be running TCP/IP for VM version 2.2 or 
TCP/IP for MVS version 2.0 or 2.2. MVS TCP/IP 
version 2.2 is required to use the model 3 with the 
TCP/IP Offload feature. 

Pricing Scenarios 

This article has focused primarily on the functional 
similarities and differences between the three mod¬ 
els of the 3172. To further illustrate the differences 
between the models, we’ve created the pricing sce¬ 
narios that follow in Table 4 on page 10. Although, 
of course, price is only one consideration when 
making a purchase of this type. In general, SNA 
Perspective believes you should consider model 1 
for channel-to-channel connectivity, model 2 for 
SNA FDDI support, and model 3 for Ethernet and 
token ring LAN connectivity or for offloading of 
TCP/IP processing (with the option of FDDI). The 
majority of existing 3172 configurations installed 
are single channel, with one or two LAN adapter 
boards, usually Ethernet And typically, if two LAN 
adapter boards are installed, they are of the same 
type. 


What the Competition Offers 

Several vendors make products that compete with 
the 3172. IBM’s staunchest competitor in this area 


is McDATA of Broomfield, Colorado. McDATA’s 
LinkMaster 6100 Netwoik Gateway Server was the 
first sophisticated LAN-to-mainftame controller and 
it was announced even before the IBM 3172. 

The Link Master 6100 can operate in several differ¬ 
ent modes, including VTAM channel-to-channel and 
as a TCP/IP server. The 6100 can also operate as a 
3172 system-compatible product supporting a simi¬ 
lar set of protocols and LANs. Configured as a 
TCP/IP server, it provides 3270 emulation for Telnet 
clients on Ethernet, tn3270, FTP, and SNMP and 
NetView manageability. The TCP/IP server 
offloads the TCP function from the mainframe, 
reducing CPU cycles. VTAM CTC provides sup¬ 
port for parallel channels, links up to T1 in speed 
and, as with all McDATA products, a high degree of 
NetView manageability. 

BusTech, Inc. (BTI) of Burlington, Massachusetts, 
is another manufacturer of 3172-like products, 
although it sources to other vendors rather than mar¬ 
keting directly. Interlink Computer Sciences, Inc. of 
Fremont, California, is one of these vendors and 
announced its 3762 Network Controller in March. 
While BTI boxes have received praise for their per¬ 
formance and price, their functionality is propor¬ 
tionally less than IBM’s or McDATA’s. Other com¬ 
panies such as Digital Equipment Corporation and 
Sun Microsystems have products for LAN-to-main- 
frame connectivity, although these products are, 
again, mostly limited to TCP/IP over Ethernet or 
DECnet over Ethernet. Both vendors OEM their 
channel adapters. 

NCR Comten of St. Paul, Minnesota, a long-time 
contender in the 37xx communication controller 
market, is expected to announce a product competi¬ 
tive to the 3172 in late 1992. The product is expect¬ 
ed to be based on the Intel microprocessor/ 
microchannel architecture like the 3172 and will be 
3172 compatible, but will probably support more 
LAN connections than IBM. SNA Perspective 
expects NCR Comten to offer TCP/IP networking 
applications such as Telnet, and 3270 emulation in 
addition to network-based routing and WAN inter¬ 
faces on its controller, similar to what it offers on its 
56xx communication controller family. 
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Competition not only exists from other vendors, but 
from IBM itself. For example, the IBM RS/6000 
with a channel adapter and TCP/IP can act as a 
TCP/IP gateway. A host software driver for VM 
will support this configuration, and MVS support is 
expected soon. IBM may even port TCP/IP Offload 
to the RS/6000. 


Conclusions 

SNA Perspective believes that, while IBM’s 
approach to the 3172 has been confusing because of 
an inconsistent focus and changing packaging of the 
product, it is responding to a very real market need. 
User surveys and studies have shown a huge interest 
in LAN-to-mainframe connectivity. Research done 
by International Data Corporation of Framingham, 
Massachusetts, shows that vendors of this type of 
product are seeing a 50 percent increase in orders. 
The market is expected to grow from $42 million 
last year to $125 million by 1996. 

While the 3172 (and products like it) target a large, 
unserved market, it is a new product with a long 
sales cycle, so its shipments to date haven’t been 
raising heads. Sales were further complicated 
because the 3172 was initially seen as a threat to 
IBM’s communication controller. Since it began 
shipping in September 1990, SNA Perspective esti¬ 
mates IBM has shipped fewer than 1,250 units— 
very few of which are model 2 units. 

The 3172 has primarily been a “piggyback” sale 
wherever TCP/IP on VM or MVS is sold, usually 
providing Ethernet connectivity. We expect this to 
continue, although the availability of the Ethernet 
adapter on the 3745 in September will affect this 
somewhat. The same will be true when FDDI 
becomes available on the 3745. But, with a fifth to 
fourth of IBM mainframes expected to be running 
TCP/IP by the end of 1993 and at least half of all 
IBM mainframe administrators considering it, the 


future is clearly bright for this product line or for 
other products that support LAN-to-mainframe 
TCP/IP support. 

From a price/performance/functionality standpoint, 
the new model 3 is a strong candidate for LAN-to- 
mainframe communications, but it has serious defi¬ 
ciencies in the FDDI support area. IBM is now 
looking at how to solve these deficiencies and we 
encourage it to do so, especially as more competi¬ 
tive FDDI devices are becoming available. 

Certainly, from a performance and configuration 
standpoint, the 3172 model 3 should replace the 
channel-attached 3174 with the token ring gateway 
as an SNA token ring interface to the host. 

The statement of direction for OSI remains unfulfilled, 
except for OSI/CS over 802.3. OSI protocol stacks 
exist for the host, but how will users access them 
from the LAN? Much has been said about the slow 
OSI sales, but unless connectivity and other key com¬ 
ponents exist, users will not buy the host software. 

Packaging of the 3172 has unfortunately gone the 
way of the 3174 (both are managed by Network 
Systems group in RTP), where each component is a 
separate and chargeable item, making it very diffi¬ 
cult for the person ordering this product for the first 
time. IBM would do itself and all its customers a 
favor by integrating some of the components and 
simplifying the process. 

SNA Perspective expects to see new models (and 
versions of ICP) still based on the Intel micro¬ 
processor/m icrochannel architecture in the future. 
This also serves to protect users investments in the 
current products. Although IBM recognizes the per¬ 
formance that results from using a RISC processor, 
it believes the Intel microprocessor will continue to 
provide sufficient performance, particularly in light 
of busmaster adapters that offload the main CPU, 
continued development by Intel on this microproces¬ 
sor family, and investment in controller software. ■ 
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3172 Pricing Scenarios 


LAN-to-Host with TCP/IP Traffic 

For LAN-to-mainframe connections supporting 


TCP/IP traffic, you can choose between the three 
models but, unless PC Network, DECnet, or FDDI 
is also required, SNA Perspective recommends 

model 3. 


Typical model 1 configuration 
(one channel connection, two LANs) 


Model 1 base unit 

16,220 

Interconnect Control Program, version 2 

5,775 

Parallel channel adapter 

8,430 

Ethernet adapter 

786 

PC Network broadband adapter 

669 


31,880 

Typical model 3 configuration 
(one channel connection, two LANs) 

Model 3 base unit 

9,680 

Interconnect Control Program, version 3 

6,350 

Parallel channel adapter 

5,100 

Ethernet adapter 

786 

Enhanced token ring 16/4 adapter 

1,030 

22,946 

FDDI LAN-to-Host with TCP/IP 

Traffic 

Typical model 2 configuration 
(one channel connection, two LANs) 

Model 2 base unit 

50,920 

Interconnect Control Program, version 3 

6,350 

Parallel channel adapter 

5,100 

Ethernet adapter 

786 

FDDI adapter 

26,250 

89,406 

Typical model 3 configuration 
(one channel connection, two LANs) 


Note: Currently, FDDI LANs are supported on model 3 
only with TCP/IP Offload. No other protocols are sup - 

ported if TCP/IP Offload is used. 

Model 3 base unit 

9,680 

Offload Hardware feature 

2,780 

OS/2 version 1.3 

200 

TCP/IP for OS/2 version 1.2.1 

200 

TCP/IP Offload software 

3,000 

Parallel channel adapter 

5,100 

Ethernet adapter 

786 

FDDI adapter (needs computer room environment) 

5,990 

27,736 


LAN-to-Host with SNA Traffic 

For LAN-to-mainframe connections supporting 
SNA traffic, you can choose between the three 
models. However, SNA Perspective recommends 
model 3 unless FDDI is required. 


Typical model 1 configuration 
(one channel connection, two LANs) 

Model 1 base unit 16,220 

Interconnect Control Program, version 2 5,775 

Interconnect Enhancement feature 2,885 

Parallel channel adapter 8,430 

Two token ring adapters 1,790 


35,100 

Typical model 2 with FDDI configuration 
(one channel connection, two LANs) 


Model 2 base unit 50,920 

Interconnect Control Program, version 2 5,775 

Interconnect Enhancement feature 2,885 

Parallel channel adapter 5,100 

Enhanced token ring adapter 1,030 

FDDI adapter 26,250 

91,960 


Typical model 3 configuration 
(one channel connection, two LANs) 


Model 3 base unit 9,680 

Interconnect Control Program, version 3 6,350 

Interconnect Enhancement feature 3,175 

Parallel channel adapter 5,100 

Two enhanced token ring adapters 2,060 

26,365 


Channel-to-Channel with SNA Traffic 

For channel-to-channel connectivity, the 3172 
family offers two options—model 1, or model 2 
with the AT&T Paradyne XL/5000 solution. 

Model 1 minimum configuration 

(one parallel channel connection, one T1) 

Note: /Is this article went to print, pricing for the 


XL/5000 was not available. 

Model 1 base unit 16,220 

Interconnect Control Program, version 2.2 5,775 

Remote Channel-to-Channel feature 21,000 

ESCON channel adapter 12,070 

T1 teleprocessing adapter 3,205 


58,270 


Table 4 
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A Chronology of Confusion 


It is not surprising that many users are confused 
about the 3172. IBM has positioned the 3172 in 
three ways in less than three years. Even those 
who understood from the SNA side that it was not 
a 3174 or 3745 or from the non-SNA side that it 
was not a bridge or a router had to contend with 
changes in the product configuration itself. 

First, it was a non-SNA LAN-to-channel box. Then 
in September 1990, it was touted as a many-proto- 
cols-over-many-LANs-to-channel box as well as 
remote channel-to-channel box. Now with this 
June’s announcements, it seems to be positioned 
as a flexible box with four distinct flavors: low-cost 
TCP/I P-and-SNA over Ethemet-and-Token Ring 
LAN-to-channel, TCP/IP or SNA over FDDI LAN- 
to-channel, TCP/IP offload LAN-to-channel, or 
remote SNA channel-to-channel. 

MAP Confusion Initially, support for 
Manufacturing Automation Protocol (MAP), a factory 
environment protocol standard based on OSI, and 
the related 802.4 token bus (carrierband and broad¬ 
band) LAN and host-based OSI manufacturing 
messaging system (OSI/MMS) software were impor¬ 
tant components of the 3172. IBM has completely 
discontinued all 3172 support for these products. 

LAN Confusion On the LAN side, the 3172 first 
supported Ethernet version 2, Ethernet 802.3, 
token bus 802.4, and token ring 802.5. In 1990, 
IBM added PC Network and FDDI. Now, IBM has 
discontinued 802.4, and supports PC Network on 
model 1 only. There are two FDDI options—users 
can combine 3172 model 3 and TCP/IP Offload 
and a low-cost FDDI adapter (that needs a class A 
computer room environment) or 3172 model 2 and 
ICP and a $26,000 FDDI board. 

Channel Confusion When the 3172 was first 
announced, the parallel or bus-and-tag channel 
was the only channel interface and was included 
in the base unit price. In 1990, when the new 
ESCON channel was announced, the 3172 cham 
nel interface became an optional feature, which 
appeared to reduce the 3172 model 1 base unit 
price by about a third. This confused many users 
and obsoleted sales force configuration models. 
This confusion seemed unnecessary because the 
3172 model 1 ESCON adapter was only available 
for channel-to-channel configurations. IBM hinted 
in 1990 at an enhanced ESCON adapter for the 
3172 model 2, but this will now be available only 
as part of the AT&T Paradyne XL/5000. 


Protocol Confusion Part I The 3172 began by 
supporting two non-SNA protocols but IBM has 
added, deleted, promised, and not discussed sev¬ 
eral others. At first, the 3172 supported TCP/IP 
and MAP. IBM added SNA support in 1990, 
though it costs extra. In addition, the 3172 model 1 
can support DECnet traffic (if the user has 
Interlink’s SNA/DECnet host software). Also in 
1990, IBM said in a statement of direction that 
OSI/CS would be supported over 802.3,802.4, 
802.5, and FDDI. However, MAP support was 
withdrawn this June, and OSI/CS is only available, 
to date, on model 1 across 802.3. Further, the 
3172 does not support two very popular LAN pro¬ 
tocols: NetBIOS and Novell’s IPX. 

Protocol Confusion Part II Some users mistak¬ 
enly believe that the 3172 provides multiple proto¬ 
cols. It actually only enables these protocols, if 
they’re installed on the mainframe, to communi¬ 
cate across the 3172 to systems with those proto¬ 
cols on a LAN. In addition to the $30,000 for the 
box, users must spend around $50,000 for 
TCP/IP, and/or $100,000 for DECnet, and/or 
$200,000 for OSI/CS on the mainframe. 

Protocol/LAN Combination Confusion Part I 
Many users mistakenly expect that any protocol 
supported by the 3172 can run over any LAN that 
can attach to the 3172. Unfortunately, it's not that 
simple, and we provide three examples: DECnet 
is only supported from Ethernet version 2 nodes, 
SNA is not supported from Ethernet version 2 
nodes, and the PC Network adapter only supports 
TCP/IP. 

Protocols/LAN Combination Confusion Part II 
IBM is pleased to say that most 3172 LAN 
adapters can support SNA or TCP/IP traffic. 
However, many users don’t know that a given 
adapter in a 3172 can only be configured to sup¬ 
port one protocol. This means, for example, that if 
both SNA and TCP/IP traffic will be sent from the 
same Ethernet LAN, the 3172 would need to have 
two Ethernet adapters attached to the same LAN. 
Although this is a source of confusion, we don’t 
see this as a major inconvenience for Ethernet 
and token ring. However, the same constraint 
holds for FDDI and we believe this is a big prob¬ 
lem. IBM says the 3172 model 2 with FDDI is 
intended for FDDI backbone support from multiple 
token ring and Ethernet LANs, but the $26,000 
FDDI adapter can only support one protocol from 
all of these LANs to the host. ■ 
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(continued from page 1) 


IBM ’s TCP/IP 

IBM has one of the richest sets of TCP/EP offerings, 
which is surprising to many. These products are 
provided across its diverse operating environments 
(see Table 5), ranging from native TCP/IP imple¬ 
mentations in AIX and feature-rich offerings for its 
MVS, VM, and OS/2 environments to basic- 
function products for operating systems such as 
OS/400 and DOS. Users of these latter operating 
systems are less likely to purchase TCP/IP for these 
systems and, if they did, would probably not need as 
extensive set of TCP/IP features. It should be noted 


that several of IBM’s TCP/EP products are packaged 
as modules, so not all of the features shown are pro¬ 
vided in the base product and may need to be pur¬ 
chased separately. 


AIX TCP/IP 

As discussed in more detail in part I of this series, 
TCP/IP has for many years been bundled with Unix 
releases from Berkeley and has since become an 
increasingly pervasive element of any Unix offer¬ 
ing. The TCP/IP planning and development for all 
AIX products are not done in IBM’s Networking 
Systems but rather in Austin, Texas, which also 
manages the RS/6000. 


IBM TCP/IP Networking Capabilities 


Platforms: 


Functions 

VM 

MVS 

OS/2 

DOS 

OS/400 

AIX/370 

AIX PS/2 

AIX/6000 

CONNECTIVITY 









Token ring 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

Ethernet 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

PC Network 

AV 

AV 

AV 

AV 

-- 

— 

— - 

— 

X.25 

AV 

AV 

AV 

— 

AV 

AV 

AV 

AV 

IEEE 802.3 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

FDDI 

AV 

AV * 

Future 

— 

— 

Future 

— 

AV 

SNAIink 

AV 

AV 

Future 

— 

— 

— 

— ‘ 

— 

HYPERchannel 

AV 

AV 

— ' 

— ' 

— 

— 

— 

— 

APPLICATION 









PROTOCOLS 









FTP C/S 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

TELNET Client 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

TELNET Server 

AV 

AV 

AV 

— 

AV 

AV 

AV 

AV 

Kerberos C/S 

AV 

Future 

AV 

— 

— 

. — 

— 

— 

Name Server 

AV 

AV 

— 

— 

— 

— 

— 

AV 

RPC 

AV 

AV 

AV 

AV 

— 

AV 

AV 

AV 

NCS 

AV 

Future 

AV 

— 

— . 

— 

—. 

AV 

LPR Client 

AV 

Future 

AV 

AV 

— 

—.. 

— 

AV 

LP Daemon 

AV 

Future 

AV 

— 

— 

— 

— 

AV 

Dynamic Routing 

AV 

AV 

AV 

AV 

— 

— 

— 

AV 

SMTP Client 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

AV 

SMTP Server 

AV 

AV 

AV 

— 

AV 

AV 

AV 

AV 

NFS Client 

— 

— 

AV 

AV 

— 

AV 

AV 

AV 

NFS Server 

AV 

AV 

AV 

— 

Future 

AV 

AV 

AV 

X-Windows Client 

AV 

AV 

Future 

— 

Future 

AV 

AV 

AV 

X-Windows Server 

— 

— 

AV 

— 

— 

— 

AV 

AV 

SNMP Monitor 

AV 

AV 

AV 

; 

— 

— 

— 

AV 

SNMP Agent 

AV 

AV 

AV 

Future 

Future 

— 

— 

AV 

REXEC Client 

AV 

AV 

AV 

AV 

— 

AV 

AV 

AV 

REXEC Daemon 

AV 

— 

AV 

— 

— 

AV 

AV 

AV 

APPLICATION 









TOOLKIT 









OSF/Motif 

AV 

AV 

Future 

— 

Future 

— 

AV 

AV 


Note: Many third-party companies offer complementary products. 
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In examining the three platforms for AIX, it is 
important to understand the different philosophies 
behind each of the implementations which are based 
on the strategic nature of the underlying hardware 
platform. 

AIX/370 

AIX/370, for example, is not a predominant operat¬ 
ing system for IBM’s mainframe environment. 
Similarly, AIX for the PS/2 is not the main operat¬ 
ing system of choice for that platform either. In 
contrast, AIX is the dominant operating environ¬ 
ment for the RS/6000. 

Ironically, IBM provides a smaller set of TCP/IP 
applications for AIX/370 than for its other main¬ 
frame implementations under MVS and VM. For 
example, AIX/370 does not currently support 
SNMP, Kerberos, domain name server, or line 
printer requester/daemon (LPR/LPD). 


supports X Windows server and the OSF/Motif 
graphical user interface. 

The reason for IBM not checking off all possible 
TCP/IP boxes for PS/2 AIX is probably because of 
the small market—AIX or Unix is rarely the operat¬ 
ing system of choice for the PS/2 (more likely to be 
DOS, Windows, or OS/2), many customers who 
want Unix on their PS/2 usually buy it from other 
vendors, and users who want an IBM Unix worksta¬ 
tion are more likely to invest in an RS/6000. 

AIX 3 for RS/6000 

Not surprisingly, the RS/6000 has the most feature- 
rich implementation of TCP/IP for AIX. TCP/IP is 
the premier networking environment for Unix work¬ 
stations and the RS/6000 is IBM’s mainline product 
for this market. IBM needs a strong implementation 
to compete against Sun Microsystems, Digital 
Equipment, HP/Apollo, and others. 


Many users have installed Unix, from IBM or one 
of several other vendors, on the mainframe. But, in 
many cases, these users primarily wanted access 
from TCP/IP to mainframe resources rather than the 
ability to run Unix applications on the mainframe. 
This primary need dovetails nicely with IBM’s pref¬ 
erence for customers to use VM or MVS as main¬ 
frame operating systems and helps to focus its 
development effort on these. Providing sockets 
support, such as the new CICS-sockets interface, 
further serves these users. 


TCP/IP for DOS 

IBM’s TCP/IP for DOS V2 provides a basic network¬ 
ing functionality to what was originally designed as 
a basic, standalone operating system. Although 
average DOS users today have more processing 
capability than they usually need, the limitations of 
the DOS operating system, such as the lack of true 
multitasking, can limit its TCP/IP support as well. 


AIX for PS/2 

On PS/2 platforms, IBM’s AIX offers about the 
same TCP/IP functionality as in AIX/370. 
However, since the PS/2 is a workstation, it also 


Take, for a start, X Windows, which IBM’s current 
implementation of TCP/IP under DOS does not 
provide. IBM announced in January that it would 
provide X Windows server support through a third 
party, Hummingbird. SNA Perspective expects that 



Note: An upgraded version of AS/400 TCP/IP has been announced every six months between its first version in AS/400 VIR2 
and its most recent version in March. 
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its performance may be weak. This, it should be 
stressed, would not be a fault with the implementa¬ 
tion but with DOS itself. 

Version 2 of TCP/IP for DOS included FTP client 
and server, which allows it to be part of a peer 
workstation network. However, TCP/IP for DOS 
can act as a client but not as a server for NFS. It 
would be a rare customer, though, who would want 
its DOS systems to be NFS servers. 

IBM has stated that a future release will include an 
SNMP agent and is also indicating that a future 
release of TCP/IP for DOS will provide full 
Microsoft Windows compatibility. 


TCP/IP for OS/2 

IBM’s TCP/IP for OS/2, currently at version 1.2.1, 
provides more TCP/IP functionality for the PS/2 
than AIX PS/2 or TCP/IP for DOS. In fact, it pro¬ 
vides almost as much as the VM and MVS imple¬ 
mentations. 

TCP/IP for OS/2 is actually several separate mod¬ 
ules. In addition to the base kit, the user can buy the 
NFS kit, the X Windows Server kit, the program¬ 
mer’s tool kit (sockets), and a module for routing IP 
over X.25. SNA Perspective believes that IBM will 
probably repackage its mainframe TCP/IP packages 
into modules. This will lower the purchase price 
and memory and storage requirements for those who 
want basic functionality. The NFS component for 
TCP/IP for VM and MVS is already a separate cost 
optional component. 


TCP/IP for the AS/400 

IBM’s implementation of TCP/IP for OS/400 is the 
least featured IBM TCP/IP offering so far. Of 
course, the AS/400 is primarily used either in a dis¬ 
tributed environment off a centralized mainframe, 
which usually involves SNA, or as a small business 
system where there is little or no other computing or 
networking. Planning and development for TCP/IP 
for OS/400 is done in Rochester, Minnesota, with all 


other AS/400 and OS/400 work, and not through 
IBM Networking Systems. 

The application functions provided for TCP/IP for 
OS/400 system are the basics: client and server for 
FTP, Telnet, and SMTP. This is not surprising since, 
traditionally, the AS/400 relies more heavily on sup¬ 
port through third parties. IBM references several 
third party packages for additional AS/400 TCP/EP 
features. IBM has announced plans to implement 
SNMP agent, NFS server, and X Windows client 
functions for OS/400. 


TCP/IP for VM and MVS 

As discussed in parts I and II of this series, some 
form of access to the mainframe via TCP/IP has 
been available for some time. However, the popu¬ 
larity of a host-based TCP/IP has been a relatively 
recent phenomenon. Users have usually made do 
with products that allowed their terminals to appear 
like 3270 terminals or used specialized products that 
gave them access to a limited range of applications 
or functions. 

The current release of TCP/IP for VM is Version 2 
Release 2, announced by IBM in December 1991. 
This product provides a feature-rich implementation 
of TCP/IP and related features, including Kerberos, 
LPR/LPD, and domain name server. In June, IBM 
announced TCP/IP Version 2 Release 2 for MVS, 
bringing the capabilities of both systems to an equal 
level. In this release, IBM also included the capa¬ 
bility for TCP/IP processing to be offloaded from an 
MVS mainframe to another device. Currently, the 
only device supporting this offload server is the 
3172 (see the other article in this issue). However, 
SNA Perspective expects that the offload server will 
be ported to the RS/6000 and perhaps to other chan¬ 
nel-attached platforms as well. 

Users Choices for TCP/IP in 
an SNA World 

SNA Perspective spoke to several users who have 
adopted TCP/IP for access to their IBM host systems. 


July. 1992 


15 



©CSI 


SNA Perspective 


We wanted to learn why TCP/IP was brought to 
their mainframe environment, the problems it had 
solved (or created), and the users’ long-term view of 
the importance of TCP/IP in an otherwise SNA world. 

Why TCP/IP? 

In most cases, the decision to add TCP/IP was not 
because MIS wanted to open the resources of the 
mainframe to the TCP/IP users. Rather, it was a 
response to the needs of those users to access those 
resources. In most cases, TCP/EP had been installed 
on the mainframe for a year and a half to two years. 

Data Download 

In most cases, the largest single user demand is for 
data. The mainframe system is often the large sin¬ 
gle repository for data and users want to gain access. 

The initial reason our respondents gave for bringing 
in TCP/BP was to give non-SNA users access to that 
data. How users gain access to mainframe data 
varies, but the most widely used approach is to use 
FTP or, less frequently, Telnet to download data 
from the mainframe to a local application. 

Storage and Output 

While some companies also want to better leverage 
mainframe resources such as storage and output 
devices, this is generally secondary to the need for 
data by the TCP/IP users. 

Applications 

Access to host applications was not as significant as 
access to data. But this seemed to be more a factor 
of lack of cooperative applications or application 
interfaces. Some companies we interviewed 
believed that, as cooperative processing allowed for 
better integration, access to host applications would 
become more important. 

Backup 

Although some companies expressed an interest in 
eventually making use of mainframe storage for 
backup over TCP/IP, few companies were actually 
doing this yet. Some companies felt that the rela¬ 
tively low cost of local disk or tape storage systems 
made backup a poor use of host resources. A com¬ 
mon sentiment was expressed by one user who said, 
“Users need the mainframe’s data. Using it as a big 
file server would be too expensive.” 


“Just Because” 

Some companies had unusual reasons for bringing 
in TCP/IP. A large Eastern United States financial 
institution originally brought in TCP/IP “because it 
was there.” The bank found the idea technically 
appealing and originally installed TCP/IP on a 
developmental system. Since then, the company has 
been adding many Unix-based workstations to its 
environment, so the appeal of using TCP/IP to 
access the host has grown substantially. 

Not Dropping SNA 

We did not find, in this survey, a stated corporate 
move away from SNA given as a reason for using 
TCP/EP. Instead, TCP/EP was seen as a good way to 
communicate with the non-IBM world, especially 
where there was a significant Unix user base. 

However, several users said that TCP/IP was seen as 
an alternative means to access resources such as 
CICS applications, because TCP/IP was simpler to 
install and tune than VTAM. Some sites indicated 
that VTAM may eventually be relegated to a sec¬ 
ondary role as TCP/IP takes hold and new applica¬ 
tions or interfaces are developed. (In the course of 
other research, we have encountered cases of com¬ 
panies completely abandoning SNA.) 

Electronic Mail 

Integration of electronic mail was not stated as a 
significant reason, at first, to add TCP/IP, although 
some users saw it emerge as a side benefit. A large 
university in the United States said it was primarily 
using PROFS mail for mainframe users and had 
begun integration to allow its Unix users to commu¬ 
nicate via the TCP/IP SMTP interface. A large 
Canadian utility saw “no need whatsoever for mail 
integration at present.” The overall feeling was that 
while mail integration was not a significant reason 
to introduce TCP/IP, it did have some long-term sig¬ 
nificance as interfaces, such as SMTP-PROFS, were 
brought into the system. 

Growing 

Whatever the reasons for bringing TCP/IP into an 
environment, the protocol usage has generally 
expanded beyond the original vision of its imple- 
menters. “Users are coming up with new reasons (to 
use TCP/IP], more applications, and things we never 
thought of when we started,” said one respondent. 
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Whose TCP/IP? 

Users have also taken a number of approaches to 
bringing TCP/IP into mainframe SNA environ¬ 
ments; in fact, we often found a combination of 
approaches in the same environment. SNA 
Perspective spoke to users of IBM’s TCP/IP for 
MVS and VM, SNS/SNA Network Integration for 
MVS from Interlink of Fremont, California, and 
gateway solutions from companies such as Open 
Connect Systems (formerly Mitek) of Carrollton, 
Texas. 

In most cases, few alternatives or competitive sup¬ 
pliers were considered in the purchase process. 

Most sites indicated that they had done little in the 
way of shopping around but rather found the first 
solution that addressed their initial needs and adopt¬ 
ed it A large university had begun many years ago 
with a developmental TCP/IP system from the 
University of Wisconsin (developed under a project 
funded by IBM and later refined and released by 
IBM as its TCP/IP for VM) and then moved to the 
commercial version. 

In most cases, and especially in more recent installa¬ 
tions, IBM’s TCP/IP product was used, selected 
largely because of the IBM name. Users believed 
that IBM’s offering would be better integrated with 
the host environment and would offer more long¬ 
term benefits. They also believe that IBM now has 
a firm commitment to making TCP/IP workable in 
their environments. 

Pros 

Nearly all users, regardless of whose product they 
adopted, said their original needs that led them to 
buy TCP/IP for mainframe access had been met by 
the solution they purchased. More importantly, 
most users also said there had been additional, unan¬ 
ticipated benefits, such as the ability to move more 
to client/server computing in a multivendor environ¬ 
ment. 

There was a lot of user excitement about the socket 
library from IBM. Users familiar with sockets felt 
this could be the basis for a great deal of application 
development, especially in environments with many 
Unix workstations. Sockets support was seen as one 


of the greatest and least-anticipated future benefits 
of TCP/IP software. 

Cons 

One financial institution expressed the need for 
more system security. It readily admitted that many 
of its concerns are not with any particular vendor’s 
implementation but with limitations of TCP/IP 
itself. Because of security concerns, the company 
does not allow FTP for data transfer to the main¬ 
frame, only from it. To ensure security, the compa¬ 
ny has purchased source code to implement its own 
security encryption algorithm. 

Another area of discontent was NFS. One user said 
the overall performance of IBM’s NFS implementa¬ 
tion was not good. This was a problem in the initial 
implementations of NFS from IBM and there was 
hope that subsequent implementations would abate 
this problem. 

Users Optimistic 

Despite these and some other problems with 
TCP/IP, most users felt that none of the problems 
were significant enough for them to consider their 
TCP/IP program disadvantageous. In fact, most 
users, regardless of which TCP/IP product they 
used, felt their significant issues would be addressed 
by future releases. 


Directions 

Most companies said they were seeking to expand 
their use of TCP/IP. One company stated that it had 
started using TCP/IP on a limited basis but now 
intended to install it on all mainframe systems. Its 
overriding concern was for data availability and 
interoperability throughout its network because 
TCP/IP allows it to accelerate the move to 
client/server computing. 

In those few sites where TCP/IP was not expanding, 
the reason given was that there were no current 
plans to change the systems as a whole. However, if 
a system were to grow, TCP/IP would likely grow 
with it. 

(continued on page 20) 
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Silver Lining in the 
SNA Internetworking 
Cloud 

by Wayne Clark 

Those of us who have been working for years in 
SNA software development are flabbergasted by all 
the current activity at the data link level. From an 
SNA perspective, the data link was quite simple— 
once written and debugged, the data link software 
and never needed to be touched. 

The simplicity and stability of the data link layer 
caught the attention of internetworking vendors. 
Most vendors of multiprotocol routers have rushed 
to embrace SLDC and LLC2 in their “SNA” prod¬ 
uct offerings. The SNA is in quotes here since those 
conversant with the details of SNA architecture 
know that the link level is not actually specified in 
SNA. Therefore, accommodating SNA by trans¬ 
porting its most common link level protocols is like 
a postal carrier saying she understands everyone’s 
mail just because she can deliver an envelope. 

The result of these efforts by internetworking ven¬ 
dors is a potpourri of product offerings that perform 
SDLC tunneling, LLC2 tunneling, and SDLC-to-LLC2 
conversion. Even IBM has joined the fray with data 
link switching (DLS) on its 6611 Network Processor. 
While most of these offerings satisfy a real market 
need, vendors don’t make clear which connectivity 
options are really possible. Marketing literature 
makes it appear as if you can do an any-to-any 
mapping but this is definitely not the case. Even so, 
this is not a major problem, as we shall see. 


Getting from Here to There 

Figure 8 shows two mainframes with channel- 
attached 3745 communication controllers accessible 
through a multiprotocol network. The 3745 on the 
left is attached to a token ring while the one on the 
right is SDLC-accessible. On the remote side 
(“remote” from the perspective of the mainframe— 
host-centered mentality dies hard) are a token-ring- 
attached 3174 cluster controller and an SDLC- 
attached 3174 or 3274 cluster controller. 



Figure 8 
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In the figure, lines A and B connect homogeneous 
data link types and are tunnels while C and D con¬ 
nect heterogeneous types and are therefore conver¬ 
sions. The tunnels in A and B can either be locally 
terminated or support passthrough. 

In the figure, A is LLC2 tunneling which, in the 
case of token ring, is also sometimes called remote 
source route bridging. This option is provided by 
IBM, Cisco Systems, CrossComm, Proteon, and 
others. B is SDLC tunneling and is implemented in 
products from Cisco Systems, CrossComm, Proteon, 
and Wellfleet. Ironically, IBM does not offer 
SDLC-to-SDLC tunneling under data link switching 
for the 6611. More will be said about this later. 

Continuing on the connectivity options in the figure, 
C is conversion from LLC2 on the host side to 
SDLC on the remote side. This capability is imple¬ 
mented in multiprotocol routers by IBM and Cisco 
Systems and in standalone products from Sync 
Research, Netlink, and Ring Access. D is the 
inverse of C—conversion of SDLC on the host side 
to LLC2 on the remote side. Interestingly, the only 
device which can do this today is the IBM 3745 
communications controller—no multiprotocol router 
handles this configuration. 

Weaning the 3745 from SDLC 

This limited SDLC support in the 6611 appears to 

be a deliberate move on IBM’s part to wean 3745s 
from SDLC attachments while encouraging integra¬ 
tion of existing remote SDLC devices with its one¬ 
way SDLC-to-LLC2 conversion option. However, 
this is not such a bad idea. Those familiar with the 
SDLC protocol will readily agree that it was 
designed for the networks of yesterday. It was 


meant to serve primarily as a point-to-point protocol 
over an unreliable medium with deterministic 
delays. From this perspective, SDLC does not inter¬ 
network well at all. 

Whether the lack of SDLC-to-SDLC support in the 
6611 will affect the success of IBM’s router remains 
to be seen. The lack of a totally symmetrical 
SDLC-to-LLC2 conversion offering, however, will 
probably not hurt IBM. Most token rings in SNA 
environments, if only installed at one end, are at the 
host end which is the neck of the funnel and there¬ 
fore requires the highest bandwidth medium. 
Choosing the conversion of host-side LLC2 to 
remote-side SDLC allows IBM to target a market 
six times larger than for local SDLC to remote 
LLC2. IBM’s backing of this asymmetrical SDLC 
conversion reinforces the belief that SDLC-to-LLC2 
conversion is a transition strategy meant to accom¬ 
modate older SNA devices that have only SDLC as 
their data link protocol. 

The lack of universal connectivity in these products 
actually serves a useful purpose. Since you can’t 
connect to just any medium from any other medium 
using these facilities, network managers will have to 
carefully examine their networks and plan their 
upgrades according to what connectivity is needed 
and what options are available. Hopefully, this 
scrutiny will lead to better overall network design. ■ 

Our guest architect, Wayne Clark, is a frequent con¬ 
tributor to SNA Perspective. His most recent arti¬ 
cle, on SDLC tunneling, was in the October 1991 
issue and his first Architect’s Corner column ran in 
February 1990. Formerly with CSI, the publisher of 
SNA Perspective, Wayne will give his third annual 
SNA interoperability tutorial at Interop this fall. 
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Conclusions 

TCP/IP has arrived at the mainframe, at the depart¬ 
ment, and on the desktop. It will not go away and, 
in fact, is growing very quickly. SNA Perspective 
believes that half of all IBM mainframe sites in the 
United States are discussing TCP/IP access and that, 
by the end of 1993, twenty to twenty-five percent of 
all mainframes in the U.S. will be accessible from 
TCP/IP. This figure will be somewhat smaller out¬ 
side the United States, but interest and installations 
are also growing much more rapidly than was 
expected even a year ago. 

We do not believe that TCP/IP will replace SNA. 
Instead, the two environments will increasingly 
coexist and new applications will draw on the 
strengths of each. 

IBM has moved from a position of “accepting” 
TCP/LP to making the protocol a major component 


of its overall communications offering. TCP/IP is 
now available, in some form, for just about every 
IBM operating environment More important, IBM 
is providing additional functionality for TCP/IP, 
such as its CICS-sockets interface, to allow TCP/IP 
users greater access to applications and resources. 

What users want, primarily, from TCP/IP on the 
mainframe is a means to access the data on the 
mainframe, as well as access to applications and 
resources that reside there. TCP/IP can also enable 
communication and access throughout the enter¬ 
prise, from client/server computing using sockets to 
mail services carried via SMTP. 

SNA users should carefully consider the direction in 
which their environments will be growing. The 
demand for TCP/IP has come from users outside the 
SNA world, but the problems of integrating TCP/IP 
into SNA environments must be solved by SNA 
professionals. Proactive solutions require consider¬ 
ation not only of what is in place today but where 
TCP/IP makes sense in the future. ■ 








In the July issue of SNA Perspective, there was an inconsistency 
between the text and Figure 8 in the "Architect's Corner" on page 18. 
Did you catch it? (The answer is below.) 

Attached is a correct version of the drawing, ready to paste over the 
original. Peal off the backing on the replacement and affix atop the 
existing figure. 


Also, while it is not exactly a mistake, to avoid confusion we would like 
to clarify a component named in Figure 2 and in the associated text on 
Page 3. The component, Communication Manager, is correct for 
OS/2 EE versions 1.3 and below. It is not correct for OS/2 version 
2.0, since the components are bundled differently. The component 
required with OS/2 version 2.0 is the OS/2 LAN Requester that is part 
of the OS/2 LAN Server version 2.0 product. 


The lines labeled C and D in the "Multiprotocol Network" cloud were switched. The line labeled C should be between the 
upper left and lower right of the cloud, while the line labeled D should be between the lower left and upper right of the cloud. 






